Dave Horsfall said: > On Wed, 12 Apr 1995, der Mouse wrote: > > > Maybe a good reason to join the crowd and not run NIS? > > > > I wish. It's clear to me that NIS is a big problem. But what else is > > out there? We have a definite need to share passwd databases across > > many machines, from multiple vendors, none of which we have source code > > to. How close to a solution can we get? > > A wild idea, straight off the top of my head: what about using the DNS > mechanisms? Apologies if this has been suggested and flamed before... A couple of points. First, in some sense, this has been implemented (successfully) before. Find information on Project Athena's Hessiod service. NIS like information was added to DNS in the form of Hessiod records. The problem is that DNS isn't very secure either, plus that's a lot more for DNS to handle, so, in general, I don't think it's a great design idea, although it's convenient to use a mechanism that's already in place. I'm surprised nobody's mentioned NIS+, although it's not available everywhere yet (and I know of no freely distributable implementation). Still, I'm not sure it's all it's cracked up to be. I must admit to being firmly in the anti-NIS camp, but mostly because I don't think it's all that useful. What does it buy you, really? It gives you a mechanism for distributing files among systems based on a master copy. Of course, since probably all the files (except passwd and possibly the shadow password file) can be modified only by System Administrators, who can distribute the files on modification via just about any means (rcp, rdist (patched!), NFS, whatever, although each has it's own share of security vulnerabilities). As I see it, NIS has three actual advantages over the "rcp" approach. First, real time password synchronization. This is nice, although it wouldn't be too hard to write a "front end" for the passwd program that makes the change and then informs (via public key encryption, perhaps) the "master password server" of the change and that information is propogated. Second, it's easy to maintain some seperate accounts or passwords on different machines within the same NIS domain. Third, one can have seperate SA groups working over the same NIS zones, and it's hard for one group to access another's machines and claim it was an accident (although it's certainly easy for them to get that access). With any method that requires .rhost trust, rlogin is just too easy. If you don't *need* any of these three features, I believe there is no good reason to run NIS. Also, the first feature would be fairly easy to replace in a considerably more secure fashion. As a footnote, in case anyone wants to point out how insecure .rhosts based access is, there are ways to make it reasonably secure. Using tcp-wrappers to restrict access to only trusted hosts and a mechanism like resolv+ or nsswitch one can have all the trusted machines in the host file which is consulted before DNS for name lookups. This is even immune to DNS based attacks, although raw IP spoofing is still possible, although difficult. In any case, it's considerably more secure, IMHO, than NIS. Nick Christenson npc@minotaur.jpl.nasa.gov